Systems and methods for use in facilitating network transactions

ABSTRACT

Systems and methods are provided for use in facilitating network transactions. In connection therewith, a server receives a request from an application of a requestor mobile device and polls sender mobile devices for location data, where a subset of the sender mobile devices is within a defined distance of the requestor mobile device. The server then receives a response from one of the subset of sender mobile devices and presents the response to the application of the requestor mobile device. Upon acceptance of the response, the server transmits the acceptance to the sender mobile device, thereby enabling delivery of an amount requested to a requestor user associated with the requestor mobile device in exchange for a digital transaction from an account of the requestor user to an account of a sender user associated with the sender mobile device.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of, and priority to, U.S.Provisional Application No. 62/811,854 filed on Feb. 28, 2019. Theentire disclosure of the above-referenced application is incorporatedherein by reference.

FIELD

The present disclosure generally relates to systems and methods for usein facilitating network transactions, and in particular, to systems andmethods for providing an automated machine, on demand, for initiatingnetwork transactions between users.

BACKGROUND

This section provides background information related to the presentdisclosure which is not necessarily prior art.

Entities are known to transfer funds through network transactions (e.g.,through digital payments, etc.). In one example, the networktransactions may involve different payment accounts, whereby usersassociated with the payment accounts purchase products or services frommerchants and/or service providers and fund the purchases by the paymentaccounts. Also, it is known for users to transfer payments to otherusers through person-to-person, or P2P, transactions, and which againinvolve payment accounts. The P2P transactions are available throughmobile applications, including, for example, the PayPal® and Venmo®mobile applications. Apart from such digital payments or transfers,users are also still known to provide checks or cash payments tomerchants and/or services providers in exchange for products orservices.

DRAWINGS

The drawings described herein are for illustrative purposes only ofselected embodiments and not all possible implementations, and are notintended to limit the scope of the present disclosure.

FIG. 1 is an exemplary system of the present disclosure suitable for usein facilitating network transactions;

FIG. 2 is a block diagram of a computing device that may be used in theexemplary system of FIG. 1;

FIG. 3 is an exemplary method that may be implemented in the system ofFIG. 1 for use in facilitating a network transaction between a senderuser and a requestor user, which includes delivery of cash to therequestor user and payment for the cash to the sender user through adigital payment transaction; and

FIGS. 4-15 illustrate exemplary interfaces that may be displayed toeither a requestor user or a sender user in the system of FIG. 1 and/orthe method of FIG. 3 to facilitate a network transaction between therequestor user and the sender user.

Corresponding reference numerals indicate corresponding parts throughoutthe several views of the drawings.

DETAILED DESCRIPTION

Exemplary embodiments will now be described more fully with reference tothe accompanying drawings. The description and specific examplesincluded herein are intended for purposes of illustration only and arenot intended to limit the scope of the present disclosure.

Transactions may be funded through a number of different mechanisms,including cash, digital payments, checks, etc. Certain merchants expresspreferences for and/or limitations to certain types of payments. Forexample, a merchant (or service provider) may not have card swipe or tapcapability, whereby conventional digital payments are not accepted bythe merchant. In various instances, therefore, a user may need cash tofund a transaction with the merchant. Or, the user may need cash to payanother user for one or more reasons. Uniquely, the systems and methodsherein permit wallet applications to perform as on-demand automatedteller machines (ATMs). In particular, when a requestor user is in needto cash, the requestor user uses the wallet application to submit a cashrequest. The wallet application, in turn, searches for one or moresender users nearby the requestor user (where, in advance of the search,the sender users are enrolled for such service). The identified senderuser(s) is(are) notified of the request and is(are) permitted to viewthe cash request and to accept the cash request. When accepted, theusers are directed to a meeting location, where the cash is thenprovided from the sender user to the requestor user, and while a digitaltransaction between payment accounts associated with the users iscommenced (through their wallet applications) (i.e., a digital P2Ptransaction). In this manner, the wallet application enables the senderuser to act as on-demand ATM to the requestor user. As such, followingthe innovations therein, cash is available not only at conventionalATMs, but also at/from sender users having the wallet applications andwilling to act as an on-demand ATMs.

FIG. 1 illustrates an exemplary system 100, in which one or more aspectsof the present disclosure may be implemented. Although the system 100 ispresented in one arrangement in FIG. 1, other embodiments may includesystems arranged otherwise depending, for example, on a manner in whichpayment account transactions are initiated, a manner in which wirelesscommunications are facilitated, users involved in the transactions, etc.

In the illustrated embodiment, the system 100 generally includes bankinginstitutions 102 and 104 and a payment network 106, each coupled to (andin communication with) one or more networks. The one or more networksare represented in FIG. 1 by the various arrowed, solid lines and eachmay include, without limitation, a local area network (LAN), a wide areanetwork (WAN) (e.g., the Internet, etc.), a mobile network, and/oranother suitable public and/or private network capable of supportingcommunication among two or more of the parts illustrated in FIG. 1, orany combination thereof. For example, one of the networks may includemultiple different networks, such as a private payment transactionnetwork made accessible by the payment network 106 to the bankinginstitutions 102 and 104 and, separately, the public Internet, which isaccessible as desired by the payment network 106 and one or more devicesassociated with users in the system 100, etc.

The banking institution 102 in the system 100 is configured to issue oneor more accounts (e.g., payment accounts, etc.). In this example, thebanking institution is associated with a user 108 (i.e., a requestoruser) and has issued a payment account for the requestor user 108.Similarly, the banking institution 104 is configured to issue one ormore accounts (e.g., payment accounts, etc.). And, in this example, thebanking institution 104 is associated with a user 110 (i.e., a senderuser) and has issued a payment account for the sender user 110. Theaccounts may include, without limitation, credit accounts, debitaccounts, prepaid accounts, savings accounts, etc. With that said, invarious embodiments, both of the banking institutions 102 and 104 may beother entities (e.g., financial or otherwise, etc.) associated with theusers in other system embodiments.

Each of the banking institutions 102 and 104 is coupled to and/or is incommunication with the payment network 106 (via one or more networks),whereby the payment network 106 is configured to facilitate transactions(broadly, network transactions) between different accounts issued by thebanking institutions 102 and 104 (and other banking institutions). Inparticular, the payment network 106 is configured to facilitateauthorization of the transactions and, later, clearing and settlement ofthe transactions between the accounts involved therein. While thepayment network 106 is provided to facilitate the transactions in thisembodiment, it should be appreciated that another service and/or entity(e.g., a P2P service provider, etc.) may be employed in other systemembodiments, in lieu of or in addition to the payment network 106, toperform one or more of these operations.

The users 108 and 110 in the system 100 are associated with mobiledevices 112 and 114, respectively. The mobile devices 112 and 114 mayeach include portable communication devices, such as, for example,smartphones, tablets, laptops, etc. And, in the illustrated embodiment,the mobile devices 112 and 114 each include a virtual wallet application116 (or P2P application). For each of the mobile devices 112 and 114,the virtual wallet application 116 includes executable instructions,stored in a non-transitory storage media within the given mobile devices112 and 114, which cause the mobile devices 112 and 114 to perform thevarious operations described herein. In various embodiments, the virtualwallet application 116 may include, for example, PayPass® fromMasterCard®, Apple Pay® from Apple®, PayWave® from Visa®, etc., or othersuitable application offered by one or more of the banking institutions102 and 104, the payment network 106, another entity, etc.

In this exemplary embodiment, the virtual wallet application 116 isinstalled in each of the mobile devices 112 and 114 and is provisionedwith a payment account credential associated with the payment accountissued to the respective one of the users 108 and 110 with which themobile devices 112 and 114 are associated. Specifically, the virtualwallet application 116 in the mobile device 112 is provided with apayment account credential for the payment account issued, by thebanking institution 102, to the requestor user 108. Likewise, thevirtual wallet application 116 in the mobile device 114 is provided witha payment account credential for the payment account issued, by thebanking institution 104, to the sender user 110. In both cases, thepayment account credential may include, for example, a token, a primaryaccount number (PAN), etc.

In connection therewith, each of the users 108 and 110 has enrolled withan “on-demand ATM” service available with/through the virtual walletapplication 116, for example, by checking/selecting a box in theapplication 116 or by otherwise designating enrollment in the virtualwallet application 116 (or associated website, etc.). In this exemplaryembodiment, the “on-demand ATM” service is included in the virtualwallet application 116 through a software development kit or SDK 118.For each of the mobile devices 112 and 114, the SDK 118 includesexecutable instructions, which cause the mobile devices 112 and 114 tooperate as described herein. The SDK 118 is a plug-in part of thevirtual wallet application 116. And, in this exemplary embodiment, theSDK 118 is provided by or on behalf of a backend server 120 of thepayment network 106. The backend server 120 is configured, by executableinstructions, to interact with the SDK 118 in order to coordinate theon-demand ATM service described herein (among other operations).

It should be appreciated that, while illustrated as part of the paymentnetwork 106 (as indicated by the dotted lines in FIG. 1), the backendserver 120 may be included and/or integrated into one of the bankinginstitutions 102 and 104, or with one or more other entities. Or, invarious embodiments, the backend server 120 may be a standalone entityspecific to providing virtual wallet functionality. In addition, whileonly described with reference to the wallet application 116, it shouldbe appreciated that the backend server 120 may interact with multipledifferent types of wallet applications (other than the virtual walletapplication 116) or other applications in general, thereby enabling theon-demand ATM service across the different applications. In general,though, the applications will include the SDK 118 to enable theon-demand ATM service described herein.

FIG. 2 illustrates an exemplary computing device 200 that can be used inthe system 100. The computing device 200 may include, for example, oneor more servers, workstations, personal computers, POS terminals,laptops, tablets, smartphones, PDAs, etc. In addition, the computingdevice 200 may include a single computing device, or it may includemultiple computing devices located in close proximity or distributedover a geographic region as a network of computing devices, so long asthe computing devices are specifically configured to function asdescribed herein. In particular, in the exemplary system 100 of FIG. 1,each of the banking institutions 102 and 104, the payment network 106,and the backend server 120 should be understood as being implemented in(and/or otherwise including) one or more computing devices consistentwith the computing device 200. In addition, the mobile devices 112 and114 are also consistent with computing device 200. That said, the system100 should not be considered to be limited to the computing device 200,as described below, as different computing devices and/or arrangementsof computing devices may be used in other embodiments. In addition,different components and/or arrangements of components may be used inother computing devices.

Referring to FIG. 2, the exemplary computing device 200 includes aprocessor 202 and a memory 204 coupled to (and in communication with)the processor 202. The processor 202 may include one or more processingunits (e.g., in a multi-core configuration, etc.). For example, theprocessor 202 may include, without limitation, a central processing unit(CPU), a microcontroller, a reduced instruction set computer (RISC)processor, an application specific integrated circuit (ASIC), aprogrammable logic device (PLD), a gate array, and/or any other circuitor processor capable of the functions described herein.

The memory 204, as described herein, is one or more devices that permitdata, instructions, etc., to be stored therein and retrieved therefrom.The memory 204 may include one or more computer-readable storage media,such as, without limitation, dynamic random access memory (DRAM), staticrandom access memory (SRAM), read only memory (ROM), erasableprogrammable read only memory (EPROM), solid state devices, flashdrives, CD-ROMs, thumb drives, floppy disks, tapes, hard disks, and/orany other type of volatile or nonvolatile physical or tangiblecomputer-readable media. The memory 204 may be configured to store,without limitation, transaction data, QR codes (or other computerreadable indicia), location data, image data, user profile data, and/orother types of data (and/or data structures) suitable for use asdescribed herein. Furthermore, in various embodiments, executableinstructions may be stored in the memory 204 for execution by theprocessor 202 to cause the processor 202 to perform one or more of theoperations described herein, such that the memory 204 is a physical,tangible, and non-transitory computer readable storage media. Suchinstructions often improve the efficiencies and/or performance of theprocessor 202 that is performing one or more of the various operationsherein. It should be appreciated that the memory 204 may include avariety of different memories, each implemented in one or more of thefunctions or processes described herein.

In addition in the exemplary embodiment, the computing device 200includes a presentation unit 206 that is coupled to (and is incommunication with) the processor 202 (however, it should be appreciatedthat the computing device 200 could include output devices other thanthe presentation unit 206, etc.). The presentation unit 206 outputsinformation (e.g., a notification associated with a cash request, animage of another user, etc.), either visually or audibly, to a user ofthe computing device 200, for example, to one or the users 108 and 110in the system 100, to users associated with other parts of the system100, etc. And, various interfaces (e.g., as defined by applications,webpages, etc.) may be displayed at computing device 200, and inparticular at presentation unit 206, to display such information. Thepresentation unit 206 may include, without limitation, a liquid crystaldisplay (LCD), a light-emitting diode (LED) display, an organic LED(OLED) display, an “electronic ink” display, speakers, etc. In someembodiments, presentation unit 206 may include multiple devices.

The computing device 200 also includes an input device 208 that receivesinputs from the user of the device (i.e., user inputs) such as, forexample, cash requests, cash request acceptances, etc. The input device208 is coupled to (and is in communication with) the processor 202 andmay include, for example, a keyboard, a pointing device, a mouse, atouch sensitive panel (e.g., a touch pad or a touch screen, etc.),another computing device, and/or an audio input device. Further, invarious exemplary embodiments, a touch screen, such as that included ina tablet, a smartphone, or similar device (e.g., the mobile devices 112and 114, etc.), may behave as both the presentation unit 206 and theinput device 208.

In addition, the illustrated computing device 200 also includes anetwork interface 210 coupled to (and in communication with) theprocessor 202 and the memory 204. The network interface 210 may include,without limitation, a wired network adapter, a wireless network adapter(e.g., a near field communication (NFC) adapter, a ZigBee adapter, anRFID adapter, a Bluetooth adapter, etc.), a global position system (GPS)adapter, a mobile network adapter, or other device capable ofcommunicating to/with one or more different networks, including one ormore of the networks in FIG. 1. Further, in some exemplary embodiments,the computing device 200 may include the processor 202 and one or morenetwork interfaces (including the network interface 210) incorporatedinto or with the processor 202.

Referring again to FIG. 1, in use/operation of the system 100, from timeto time, the requestor user 108 will be in need of cash to transact witha merchant, service provider, or another user. However, an ATM may notbe available to the user 108 or the user 108 may not have available cashin a checking account accessible through the ATM. As such, through thepresent disclosure, the requestor user 108 can initiate the on-demandATM service included in the virtual wallet application 116 at his/hermobile device 112.

Specifically, the requestor user 108 accesses the wallet application 116at the mobile device 112 (thereby initiating a session) andauthenticates himself/herself thereto (e.g., by biometric, PIN,passcode, etc.). The SDK 118 of the wallet application 116 is theninitialized, which in turn configures the mobile device 112 to generatea session key (or session ID) for the mobile device 112 and for thecurrent interaction (or session) by the requestor user 108 with thewallet application 116. Thereafter, as part of the session, the mobiledevice 112, as configured by the wallet application 116 and/or the SDK118, provides the option to the user 108 to submit a cash request toanother wallet user (e.g., the sender user 110, etc.). When selected,the mobile device 112, as configured by the wallet application 116and/or the SDK 118, identifies a location of the mobile device 112(e.g., by GPS or GeoIP, etc.), solicits an amount of cash to be“withdrawn”, and solicits an image of the user 108 (e.g., a facialimage, etc.). In response, the requested amount and the image areprovided/presented by the user 108, whereby the mobile device 112, asconfigured by the wallet application 116 and/or the SDK 118, receivesand/or captures the amount and the image. That said, either afteraccessing the wallet application 116 or after selection of the option tosubmit a cash request, the mobile device 112, as configured by thewallet application 116 and/or the SDK 118, either generates the sessionID for the cash request (as described above) or, alternatively, in otherembodiments, the mobile device 112 may be configured to receive (orretrieve) the session ID from the backend server 120 for the givensession/interaction with the wallet application 116. The mobile device112, as configured by the wallet application 116 and/or the SDK, thencompiles a cash request (including an identifier associated with theuser 108 (and/or the account and/or the wallet application 116 (e.g., anapplication ID, etc.), etc.), the amount of cash, the image of the user108 (and/or one or more other biometrics of the user 108), the locationof the mobile device 112, and the session ID for the cash request,etc.). In various embodiments, the cash request is protected throughchannel level encryption (e.g., SSL encryption, etc.), whereby data maybe provided through an established authenticated channel from the mobiledevice 112 to the backend server 120 (e.g., and potentially extending tothe mobile device 112 and the payment network 106, etc.). Then, themobile device 112, as configured by the wallet application 116 and/orthe SDK 118, transmits the cash request to the backend server 120.

In turn, the backend server 120 is configured to validate the cashrequest and/or the requestor user 108. For example, the backend server120 may be configured to validate the image of the user 108 against areference image for the user 108 (e.g., associated with the accountissued by the banking institution 102, provided during registration ofthe virtual wallet application 116, etc.). To do so, the backend server120 may be configured to call an application programming interface (API)associated with one or more validation services, whereby a result isreturned by the validation service(s) (e.g., via a suitable notificationservice associated with the mobile device 112, etc.) indicative of thematch or no match of the image of the user 108 to one or more referencesassociated with the user 108 and/or the user's account. The backendserver 120 may be further configured to validate the cash request basedon the application ID, session ID or the identifier included in the cashrequest (e.g., based on the session ID generated by the mobile device112 (or, in some embodiments, by the backend server 120), a profileassociated with the wallet application 116 and/or the requestor user108, etc.).

When the cash request is validated (e.g., by way of validating the imageof the user 108, etc.), the backend server 120 is configured to poll oneor more mobile devices that are enrolled to be “on-demand ATMs” todetermine a location of the mobile devices (e.g., to request, retrieve,etc. location data for the mobile devices, etc.). That is, only themobile devices enrolled to be an on-demand ATM are polled in thisexemplary embodiment. In response, the mobile device 114 (i.e., anenrolled mobile device), for example, as configured by the virtualwallet application 116 and/or the SDK 118 (and/or an operating system ofthe mobile device 114), determines and responds with its location (e.g.,via GPS or GeoIP, etc.). The backend server 120 is configured to thenselect one or more of the responding mobile devices (e.g., the mobiledevice 114, etc.) within the vicinity of the mobile device 112 (e.g.,within 0.5 miles, within 1 mile, within 3 miles, etc.) (i.e., nearbymobile devices) (as a subset of the responding mobile devices). Itshould be appreciated that the backend server 120 may be furtherconfigured to select the mobile device based on information associatedwith the mobile device, accounts provisioned thereto, and/or usersthereof (e.g., age of a corresponding account, a service rating of theuser, prior on-demand ATM activity, etc.). The backend server 120 isconfigured to then push a notification to each of the selected mobiledevices (e.g., via suitable notification services associated with themobile devices, etc.), including the mobile device 114 (in thisembodiment, as a selected mobile device), via the virtual walletapplication 116 and/or the SDK 118.

Upon receipt of the notification from the backend server 120, the mobiledevice 114, as configured by the wallet application 116 and/or the SDK118, displays a notification (e.g., an application banner, etc.) to theuser 110. The user 110, in turn, may either select the notification toview details of the requested transaction (thereby initiating a session)or ignore the notification. When selected, the mobile device 114, asconfigured by the wallet application 116, initializes the SDK 118,which, in turn, causes the mobile device 114 to generate a session IDfor the mobile device 114 and for the current interaction (or session)by the sender user 110 with the wallet application 116 (or, potentially,in other embodiments, causes the mobile device 114 to instead requestand receive/retrieve the session ID from the backend server 120 for thegiven session/interaction with the mobile device 114 and walletapplication 116) (e.g., based on preconfigured logic, etc.) and then tocommunicate the session ID to the backend server 120 (e.g., via thechannel level encryption therebetween, etc.). The backend server 120 isconfigured to receive the session ID and to validate the session ID fromthe mobile device 114 (e.g., to ensure security and/or to controlvalidations for threats, etc.) (e.g., based on preconfigured session IDvalidate logic, etc.) Thereafter, the mobile device 114, as configuredby the wallet application 116 and/or the SDK 118, displays the detailsof the cash request to the user 110. The details of the cash requestinclude, generally, the amount of cash desired. The cash request, asdisplayed, may further includes the image of the user 108 (and/or one ormore other biometrics of the user 108) and one or more details about theuser 108 (e.g., a general location, etc.). The user 110 may then decidewhether to accept the cash request (e.g., depending on whether the userpossesses the desired cash, the image of the user 108, or other relevantreason, etc.). When the user 110 decides to accept the cash request, theuser 110 provides an accept input to the mobile device 114. Inconnection therewith, the mobile device 114, as configured by the walletapplication 116 and/or the SDK 118, solicits a location at which to meet(e.g., a nearby merchant, etc.), a designation of an estimated deliverytime, and an image of the user 110. Upon receipt of the same, the mobiledevice 114, as configured by the wallet application 116 and/or the SDK118, provides the acceptance, the location to meet, the estimateddelivery time, and the image of the user 110 (and potentially, otheridentifying information associated with the user 110 (such as one ormore other biometrics of the user 110, etc.) and/or the user's account,etc.) to the backend server 120 (e.g., via the channel level encryptiontherebetween, etc.).

The backend server 120 is configured to provide the acceptance from themobile device 114 (and from other mobile devices within the vicinity ofthe mobile device 112, if applicable), to the mobile device 112, andspecifically, the virtual wallet application 116 and/or SDK 118 therein.It should be appreciated that the backend server 120 may be configuredto filter out ones of the acceptances based on, for example, a rating ofthe sender user, the estimated time and/or meet location of theacceptance, etc., prior to submitting the final ones of the acceptancesto the user 108.

Upon receipt, the mobile device 112, as configured by the walletapplication 116 and/or the SDK 118, displays the acceptance(s) to theuser 108, including the various data associated therewith (e.g., themeet location and the estimated time (and potentially, the image of theuser 110), etc.). The user 108 then selects the user 110, in thisexample, to be the on-demand ATM, for example, based on the convenienceof the meet location and the estimated time, etc. In connectiontherewith, the mobile device 112, as configured by the walletapplication 116 and/or the SDK 118, provides a selection of theacceptance of the user 110 to the backend server 120.

In this exemplary embodiment, the backend server 120 is configured tonotify each of the sender users who accepted the cash request of eitherbeing selected or not. For the selected sender user (i.e., the senderuser 110 in this example), the backend server 120 is configured toprovide a notification to the users 108 and 110 with instructions tomeet at the location at the estimated time, as indicated by the user 110in his/her response. And, the users 108 and 110 proceed to the locationto meet. Once at the location, the users 108 and 110 identify each otherfrom the images of the other user at the mobile devices 112 and 114. Theusers 108 and 110 then initiate a P2P digital transaction between theaccounts provisioned to the virtual wallet application 116, and then (orat the same time), the user 110 provides the cash to the user 108. Inparticular, when the cash is received by the user 108, the user 108provides a cash received input to the mobile device 112. In turn, themobile device 112, as configured by the wallet application 116 and/orthe SDK 118, provides a payment account credential to the mobile device114 (e.g., in a form of a QR code, including the credential, the sessionID for the mobile device 112, etc. via NFC communication; etc.), and themobile device 114, as configured by the wallet application 116 and/orthe SDK 118, initiates the transaction through the payment network 106and the backend server 120 (i.e., a pull transaction processed by thepayment network 106 and the banking institutions 102 and 104 in aconventional manner). It should be appreciated that the transaction maybe initiated in the opposite direction as well (i.e., as a pushtransaction by the mobile device 112) (prior to or after delivery of thecash from the sender user 110 to the requestor user 108).

When complete, the backend server 120 is configured to transmit an eventnotification of the transfer to each of the users 108 and 110, at themobile devices 112 and 114 (and at the virtual wallet application 116therein).

FIG. 3 illustrates an exemplary method 300 for use in facilitating anetwork transaction through use of an on-demand ATM service (and whichmay implemented through the system 100). The exemplary method 300 isdescribed with reference to the mobile device 112 (and the virtualwallet application 116 and SDK 118 therein), the mobile device 114 (andthe virtual wallet application 116 and SDK 118 therein), and the backendserver 120, as well as other aspects of the system 100, and also to thecomputing device 200. However, it should be understood that the method300 is not limited to the system 100 or the computing device 200. And,likewise, the systems and the computing devices herein should not beunderstood to be limited to the exemplary method 300.

In addition, the method 300 is described with reference to the multipleexemplary interfaces 400-1500 in FIGS. 4-15, which include multipleinterfaces to be displayed to the requestor user 108 or the sender user110 (at their respective mobile devices 112 or 114) (e.g., atpresentation units 206 thereof, etc.) in connection with performing anetwork transaction for cash through use of the on-demand ATM servicesdescribed herein (in exchange for a P2P digital transaction). However,the method 300, and more generally the methods and systems describedherein, should not be understood to be limited to the exemplaryinterfaces 400-1500 provided herein, as other interfaces may be providedto the users 108, 110 in other embodiments.

Initially in the method 300, it should be understood (as describedabove) that each of the users 108 and 110 have the virtual walletapplication 116 installed and active in their mobile devices 112 and114, respectively. In addition, each is enrolled with the on-demand ATMservice, to be an on-demand ATM, whereby the users 108 and 110 arewilling to provide cash in exchange for a P2P digital transaction.

In this example, the user 108 decides to purchase a product for $30 froma merchant (not shown), which only accepts cash, but the user 108 onlyhas $5 in cash. As such, the user 108 is in need of additional cash(i.e., $25). Consequently, the user 108 launches, at 302, the virtualwallet application 116 at the mobile device 112 and selects the“on-demand ATM” option, which causes the SDK 118 at the mobile device112 to be initialized, at 304. When initialized, the SDK 118communicates with the backend server 120, which causes the backendserver 120 (in this embodiment) to generate and register in memory(e.g., the memory 204, etc.), at 306, a session ID for the mobile device112 (and the current interaction of the requestor user 108 with thewallet application 116 at the mobile device 112) and returns, at 307,the session ID to the mobile device 112. In connection therewith, theuser 108 may be authenticated when launching the wallet application 116and/or selecting the “on-demand ATM” option (at 302) (although this isnot required in all embodiments). In connection therewith, FIG. 4illustrates an exemplary interface 400 that may be displayed to therequestor user 108 at the mobile device 112 (via the wallet application116) (e.g., as part of operation 302, etc.), wherein upon launching thewallet application 116, the user 108 is requested to authenticatehimself/herself by use of a fingerprint (or other biometric) (or,alternatively, by use of a passcode, a PIN, or a password, etc.). FIG. 5then illustrates an exemplary interface 500 in which, upon accessing thewallet application 116, the requestor user 108 may select the desiredpayment account (and corresponding payment card 502) to fund theunderlying P2P digital transaction and the on-demand ATM option 502 toinitiate the on-demand ATM service (and transaction).

Thereafter, the user 108 initiates, at 308, a cash request (e.g., byselecting the on-demand ATM option in the exemplary interface 500,etc.), after which the user 108 enters an amount of cash desired andselects to submit the cash request. The cash request includes,generally, an amount of cash needed (e.g., $25 in this example, etc.).FIG. 6 illustrates an exemplary interface 600 that may be displayed tothe requestor user 108 at the mobile device 112 (via the walletapplication 116 and/or the SDK 118), wherein the user 108 is able toenter the amount of cash desired (e.g., $25 in this example, etc.) andselects to submit the cash request. In response to the cash request, thevirtual wallet application 116 of the recipient user 108 captures, at310, a location of the mobile device 112 (e.g., a latitude and longitudeor other suitable location indication, etc.) and an image of the user108 (e.g., a selfie or facial image, etc.). The mobile device 112 thentransmits, at 312, the cash request to the backend server 120. The cashrequest includes, in addition to the requested amount of cash, one ormore identifiers of the user 108, the mobile device 112, and/or thevirtual wallet application 116 (e.g., a name of the user 108, the user'saccount number, etc.), as well as the location of the mobile device 112,the image of the user 108, and, potentially, the session ID for themobile device 112, etc. It should be appreciated that the image of theuser 108, for example, may be omitted from the cash request in one ormore embodiments (e.g., where the image is already stored in the backendserver 120 or otherwise.

In turn in the method 300, the backend server 120 validates the cashrequest and the image of the user 108, at 314. In particular, forexample, the backend server 120 validates that the cash request is anauthentic request (e.g., based on the session ID for the mobile device112 or otherwise, etc.), that the user 108 is an authorized user of thewallet application 116 (or associated account) and/or mobile device 112,that the mobile device 112 is associated with the request for theon-demand ATM service, and/or that the mobile device 112 is associatedwith the user 108, etc. The validation may also include, optionally, avalidation of the image provided by the user 108, against a referencewithin the backend server 120, the payment network 106, or even thebanking institution 102, etc. It should be appreciated that the backendserver 120 may rely on internal services (e.g., within the backendserver 120 and/or the payment network 106, etc.) or on services providedfrom other entities, including, for example, the banking institutions102 and 104, etc., to facilitate such validation. In one example, thevalidation may be provided by the banking institution 102 that issuedthe account to the user 108 and/or provides the wallet application 116.The backend server 120 also associates the cash request with the sessionID for the mobile device 112, if the session ID is not already includedin the cash request itself.

Once validated, the backend server 120 identifies, at 316, potentialsender users (as sources of cash for the requestor user 108). Theidentification may be limited to users enrolled in the on-demand ATMservice, for example, or may include selection amongst all availableusers having the virtual wallet application 116. In addition, theidentification may limit users based on ratings of the users, historicalon-demand ATM performance, etc. In one particular example, the backendserver 120 initially identifies a total number of participating users,and then selects or ranks the participating users based on pastparticipation and performance for the on-demand ATM service (e.g., ahigh performing user is prioritized over low performing users (e.g.,based on on-time/prompt participation, issueless exchanges, userratings, etc.), users having participated twenty or eight times areprioritized over users having participated once or never, orcombinations thereof, etc.). It should be appreciated that common, knownor home locations of users may also be employed to identify and/orselect/rank participating users, etc. The backend server 120 then pollsthe identified sender users, or the mobile devices associated therewith,for their location, at 318. In FIG. 3, the sender user 110 isidentified, and therefore the backend server 120 polls the mobile device114 for its location, at 318. The mobile device 114, like other mobiledevices for identified sender users, responds, at 320, with the locationof the mobile device 114. The backend server 120 may then count thenumber of respondents within one or more defined radiuses of therequestor user 108, and may further enforce a minimum threshold count ofsender users in order to proceed with the cash request.

The backend server 120 then selects one or more of the responding mobiledevices, as associated with identified sender users, based on a locationof the mobile devices. Specifically, the backend server 120 may selectmobile device within 0.5 miles, 1 mile, 2 miles, 5 miles, or some othersuitable distance, etc., of the mobile device 112 (i.e., within adefined distance). In addition to distance, optionally, the backendserver 120 may rely on a rating of a sender user, historical on-demandATM activities, an age of a sender user's account (i.e., wallet accountor payment account provisioned to the wallet application 116, etc.),etc. to help provide an additional level of security and integrity tounderlying transactions. In this example, the backend server 120 selectsthe mobile device 114 because the mobile devices is within 0.25 miles ofthe location of mobile device 112 included in the cash request. As such,the backend server 120 transmits the cash request, at 322, to the mobiledevice 114 (and similarly does so for other mobile devices within thedefined distance).

In turn, the cash request is received at the mobile device 114 and, at324, a notice is displayed to the sender user 110, at the mobile device114 (e.g., via presentation unit 206, etc.). When the sender user 110selects the notice, at 326, the SDK 118 at the mobile device 114 isinitialized and the cash request is displayed to the sender user 110, at328 (e.g., after prompting the user 110 to authenticate himself/herselfto the mobile device 114 and/or wallet application 116, etc.). Likeabove, when the SDK 118 is initialized, the mobile device 114communicates with the backend server 120, which, in turn, in thisembodiment, generates and registers a session ID for the mobile device114 and returns the session ID to the mobile device 114. That said, thesender user 110 is permitted to view the cash request and determine ifhe/she has sufficient cash, on hand, to perform as the on-demand ATM forthe requestor user 108. The sender user 110 may also rely on othercriteria to decide to accept the cash request, or not, including alocation of the requestor user 108, an image of the requestor user 108,a time of day, a day of the week, a rating of the requestor user 108(e.g., an integrity rating, etc.), availability of meeting locations inthe given area, etc. When the sender user 110 decides to accept the cashrequest, at 330, the sender user 110 provides a meet location (i.e., alocation to deliver the cash) and an estimated time to the meet locationto the mobile device 114. The mobile device 114 then transmits, at 332,a response, which includes the acceptance, the meet location and theestimated time, to the backend server 120.

FIG. 7 illustrates an exemplary interface 700 that may be displayed tothe sender user 110 at the mobile device 114 (via the wallet application116), through which a visual notice (or other notification other than avisual notice, such as a sound, etc.) (e.g., an application banner,etc.) is displayed (or otherwise presented) to the user 110 indicatingthat a cash request has been submitted and that the user 110 has beenselected to participate as an on-demand ATM (e.g., at operation 324,etc.). FIG. 8 illustrates an exemplary interface 800 that may bedisplayed to the sender user 110 at the mobile device 114 (via thewallet application 116) upon selection of the notice at the interface700, wherein the wallet application 116 launches and the user 110 isrequested to authenticate himself/herself by use of a fingerprint (or,alternatively, by use of a PIN). And, FIGS. 9 and 10 illustrateexemplary interfaces 900 and 1000 that may be displayed to the senderuser 110 at the mobile device 114 (via the wallet application 116),following his/her authentication thereto, wherein the user 110 can viewinformation relating to the requestor user 108 (and the given cashrequest), such as a photo of the user 108, a location of the user 108,and an amount of the cash request (via interface 900) (all of which maybe used by the sender user 110 in deciding to accept the cash request byselecting the “Let's Go” button 902 (or not). In this example, theinterface 1000 also permits the sender user 110 to provide a meetlocation and an estimated time to the meet location (via interface1000), upon initially determining to accept the cash request of therequestor user 108 (via the interface 900), and then confirm acceptanceof the cash request (via interface 1000) (and/or transmit a response tothe backend server 120) (e.g., at operations 330 and 332, etc.).

Next in the method 300, the backend server 120 provides the responsefrom the sender user 110 (and his/her mobile device 114), at 334, to themobile device 112 (along with any other responses received from othermobile devices). The response includes, for each sender user, the meetlocation, the estimated time to meet, and the image of the sender user(and, potentially, other integrity data regarding the sender user 110such as that described herein for the requestor user 108, etc.).

Upon receipt of the response, the mobile device 112 displays, at 336,the response(s) to the requestor user 108. Like with the sender user110, the requestor user 108 then decides whether to accept theresponse(s), or not. When the requestor user 108 accepts a response, at338, the mobile device 112 transmits an acceptance, by the requestoruser 108, to the backend server 120, at 340. The backend server 120 thentransmits the acceptance, by the requestor user 108, to the sender user110 at the mobile device 114, at 342. In addition (although not shown),the backend server 120 notifies each of the other sender users, who'sresponse was not accepted by the requestor user 108. FIG. 11 illustratesan exemplary interface 1100 that may be displayed to the requestor user108 at the mobile device 112 (via the wallet application 116), throughwhich a visual notice (or other notification other than a visual notice,such as a sound, etc.) is displayed (or otherwise presented) to the user108 indicating acceptance of his/her cash request. And, FIG. 12illustrates an exemplary interface 1200 that may be displayed to therequestor user 108 at the mobile device 112 (via the wallet application116) upon selection of the notice at the interface 1100, wherein thewallet application 116 again launches and displays details associatedwith the user that accepted the cash request (i.e., the sender user 110in this example). In so doing, the interface 1200 also includesinformation relating to the sender user 110 (and his/her acceptance ofthe given cash request), such as a photo of the user 110, a location ofthe user 110, and an amount of the cash request (all of which may beused by the requestor user 108 in deciding to accept the proposal fromthe user 110 via the “Let's Go” button 1202 (or not).

Finally in the method 300, once the users 108 and 110 are at the meetlocation, and meet, at 344, the cash is delivered from the sender user110 to the requestor user 108, and the requestor user 108 and the senderuser 110 initiate a P2P digital transaction, via their walletapplications 116. It should be appreciated that the delivery of the cashmay be before or after the initiation of the P2P digital transaction (orsubstantially at the same time). In this exemplary embodiment, however,the cash is delivered first. In particular, when at the meet location,the wallet application 116 displays the image of the requestor user 108at the mobile device 114 and, likewise, the wallet application 116displays the image of the sender user 110 at the mobile device 112. Whenone identifies the other, the users 108 and 110 engage one another andthe cash is delivered to the requestor user 108. In response, one orboth of the users 108 and 110 provide an input for “cash delivered” tothe wallet application 116 at their respective one of the mobile devices112 and 114, whereupon the wallet application 116 enables payment. Thepayment may then be facilitated through a NFC connection (or tap)between the mobile devices 112 and 114, or otherwise.

In one example, and with reference to FIGS. 13 and 14, in response to a“cash delivered” input at the mobile device 112 by the requestor user108, the wallet application 116 displays a QR code (or other indicia),which encodes a payment account credential for the requestor user'spayment account (as issued by the banking institution 102), along withthe details of the transaction (e.g., location, amount, session ID forthe mobile device 112, etc.). In particular, the user 108 may select the“QR Payment” button 1302 at the interface 1300 of FIG. 13 to confirmthat the transaction has taken place. In response, the QR code isdisplayed at the mobile device 112 (via interface 1400). The sender user110, in turn, scans the QR code with the wallet application 116 inhis/her mobile device 114 (e.g., via interface 1402, etc.), which causesthe wallet application 116 in the mobile device 114 to initiate a pulltransaction between the requestor user's payment account (as issued bythe banking institution 102) and the sender user's payment account (asissued by the banking institution 104). Settlement of the resulting P2Ptransaction between the banking institution 102 and the bankinginstitution 104 may then be performed via intra-bank settlement (whenthe institutions 102 and 104 are on (or are part of) the same network),or may be performed by a separate P2P service (e.g., Mastercard Send,etc.).

As an alternative, in response to a “cash delivered” input at the mobiledevice 114 by the sender user 110, the wallet application 116 maydisplay a QR code (or other indicia), which encodes a payment accountcredential for the sender user's payment account (as issued by thebanking institution 104), along with the details of the transaction(e.g., location, amount, session ID for the mobile device 114, etc.).The requestor user 108, in turn, scans the QR code with the walletapplication 116 in the mobile device 112, which causes the walletapplication 116 in the mobile device 112 to initiate a push transactionfrom the requestor user's payment account to the sender user's paymentaccount (as issued by the banking institution 104).

In either case, when the P2P transaction is approved, the backend server120 is notified (e.g., via the underlying rails processing thetransaction such as the institutions 102 and 104, the P2P service,etc.). The backend server 120 then confirms the transaction, at 346,with the mobile device 112 (i.e., the requestor user 108) and alsoconfirms the transaction, at 348, with the mobile device 114 (i.e., thesender user 110). The requestor user 108 and the sender user 110 areable to report any issues with the delivery of cash, then, through theconfirmation of the transaction, or otherwise, when issues arise. FIG.15. Illustrates an exemplary interface 1500 that may be displayed to thesender user 110 at the mobile device 114 (via the wallet application116), through which a confirmation may be presented confirming the P2Ptransaction (and corresponding payment to the user 110).

It should be appreciated that in the various P2P transactions describedherein, the session IDs for the devices involved in the transactions aregenerally persistent in messages associated with the transactions (e.g.,the cash requests, responses, acceptances, authorization requests,authorization replies, etc.) and through completion of the transactions.As such, the session IDs may be used as a basis for matching and/oridentifying the transactions or messages associated with the on-demandATM services (or transaction associated therewith), etc.

In view of the above, the systems and methods herein permit theproliferation of on-demand ATMs to users and/or locations unserved byconventional ATMs (and potentially without specific cash-withdrawaland/or debit accounts). The on-demand ATM services rely on technology toimplement P2P digital transactions (in exchange for cash), at times andplaces acceptable to the users involved, whereby cash may be deliveredin person and in connection with data flow between the requestor users'wallet applications and the sender users' wallet applications isdistinct from conventional payment flows. What's more, the historicaldata related to the locations, at which the cash delivery occurs,provides insights into potential placement of conventional ATMs, as aform of actual use intelligence.

Again and as previously described, it should be appreciated that thefunctions described herein, in some embodiments, may be described incomputer executable instructions stored on a computer readable media,and executable by one or more processors. The computer readable media isa non-transitory computer readable storage medium. By way of example,and not limitation, such computer-readable media can include RAM, ROM,EEPROM, CD-ROM or other optical disk storage, magnetic disk storage orother magnetic storage devices, or any other medium that can be used tocarry or store desired program code in the form of instructions or datastructures and that can be accessed by a computer. Combinations of theabove should also be included within the scope of computer-readablemedia.

It should also be appreciated that one or more aspects of the presentdisclosure transform a general-purpose computing device into aspecial-purpose computing device when configured to perform thefunctions, methods, and/or processes described herein.

As will be appreciated based on the foregoing specification, theabove-described embodiments of the disclosure may be implemented usingcomputer programming or engineering techniques including computersoftware, firmware, hardware or any combination or subset thereof,wherein the technical effect may be achieved by performing at least oneof the following operations: (a) receiving, by a backend server, arequest (e.g., a cash request, etc.) from an application (e.g., a walletapplication, etc.) of a requestor mobile device associated with arequestor user, the request including an amount (e.g., of cash, etc.)requested and a location of the requestor mobile device, the requestoruser associated with a first account (e.g., a first payment account,etc.); (b) polling, by the backend server, sender mobile devices forlocation data, each of the sender mobile devices associated with asender user; (c) receiving, by the backend server, location data fromeach of the sender mobile devices, wherein a subset of the sender mobiledevices are within a distance of said location of the requestor mobiledevice; (d) transmitting, from the backend server, the request to thesubset of the sender mobile devices; (e) receiving a response (e.g., acash response, etc.) from one of the subset of the sender mobiledevices, the response including a meet location and an estimated time;(f) presenting, by the backend server, the response to the applicationof the requestor mobile device; (g) in response to an acceptance of theresponse form the requestor user at the application of the requestmobile device, transmitting the acceptance to the one of the subset ofthe sender mobile devices, thereby enabling delivery of the amountrequested to the requestor user in exchange for a digital transactionfrom said first account to a second account (e.g., a second paymentaccount, etc.) associated with the sender user of the one of the subsetof the sender mobile devices; (h) validating the request, based on theimage of the requestor user included in the request, prior to pollingthe sender mobile devices; and (i) transmitting a confirmation of theexchange to the requestor mobile device and/or the one of the subset ofthe sender mobile devices.

Exemplary embodiments are provided so that this disclosure will bethorough, and will fully ‘convey the scope to those who are skilled inthe art. Numerous specific details are set forth such as examples ofspecific components, devices, and methods, to provide a thoroughunderstanding of embodiments of the present disclosure. It will beapparent to those skilled in the art that specific details need not beemployed, that example embodiments may be embodied in many differentforms and that neither should be construed to limit the scope of thedisclosure. In some example embodiments, well-known processes,well-known device structures, and well-known technologies are notdescribed in detail.

The terminology used herein is for the purpose of describing particularexemplary embodiments only and is not intended to be limiting. As usedherein, the singular forms “a,” “an,” and “the” may be intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. The terms “comprises,” “comprising,” “including,” and“having,” are inclusive and therefore specify the presence of statedfeatures, integers, steps, operations, elements, and/or components, butdo not preclude the presence or addition of one or more other features,integers, steps, operations, elements, components, and/or groupsthereof. The method steps, processes, and operations described hereinare not to be construed as necessarily requiring their performance inthe particular order discussed or illustrated, unless specificallyidentified as an order of performance. It is also to be understood thatadditional or alternative steps may be employed.

When a feature is referred to as being “on,” “engaged to,” “connectedto,” “coupled to,” “associated with,” “included with,” or “incommunication with” another feature, it may be directly on, engaged,connected, coupled, associated, included, or in communication to or withthe other feature, or intervening features may be present. As usedherein, the term “and/or” and “at least one of” includes any and allcombinations of one or more of the associated listed items.

In addition, as used herein, the term product may include a good and/ora service.

Although the terms first, second, third, etc. may be used herein todescribe various features, these features should not be limited by theseterms. These terms may be only used to distinguish one feature fromanother. Terms such as “first,” “second,” and other numerical terms whenused herein do not imply a sequence or order unless clearly indicated bythe context. Thus, a first feature discussed herein could be termed asecond feature without departing from the teachings of the exampleembodiments.

None of the elements recited in the claims are intended to be ameans-plus-function element within the meaning of 35 U.S.C. § 112(f)unless an element is expressly recited using the phrase “means for,” orin the case of a method claim using the phrases “operation for” or “stepfor.”

The foregoing description of exemplary embodiments has been provided forpurposes of illustration and description. It is not intended to beexhaustive or to limit the disclosure. Individual elements or featuresof a particular embodiment are generally not limited to that particularembodiment, but, where applicable, are interchangeable and can be usedin a selected embodiment, even if not specifically shown or described.The same may also be varied in many ways. Such variations are not to beregarded as a departure from the disclosure, and all such modificationsare intended to be included within the scope of the disclosure.

What is claimed is:
 1. A computer-implemented method for use infacilitating a network transaction, the method comprising: receiving, bya backend server, a request from an application of a requestor mobiledevice associated with a requestor user, the request including an amountand a location of the requestor mobile device, and wherein the requestoruser is associated with a first account; polling, by the backend server,multiple sender mobile devices for location data, each of the sendermobile devices associated with a sender user; receiving, by the backendserver, location data from each of the multiple sender mobile devices,wherein a subset of the multiple sender mobile devices is within adistance of said location of the requestor mobile device; transmitting,from the backend server, the request to the subset of the multiplesender mobile devices; receiving a response from one of the subset ofthe multiple sender mobile devices, the response including a meetlocation and an estimated time; presenting, by the backend server, theresponse to the application of the requestor mobile device; and inresponse to an acceptance of the response from the requestor user at theapplication of the requestor mobile device, transmitting the acceptanceto the one of the subset of the sender mobile devices, thereby enablingdelivery of the amount to the requestor user, in person, in exchange fora digital transaction from said first account to a second accountassociated with the sender user of the one of the subset of the sendermobile devices.
 2. The computer-implemented method of claim 1, whereinthe request includes a cash request; wherein the application includes awallet application; wherein the amount includes an amount of cashrequested; and wherein the cash request further includes a biometricand/or a facial image of the requestor user.
 3. The computer-implementedmethod of claim 2, further comprising validating the cash request, basedon the biometric and/or the facial image of the requestor user includedin the cash request, prior to polling the sender mobile devices.
 4. Thecomputer-implemented method of claim 3, further comprising causing thebiometric and/or the facial image of the requestor user to be displayedto the sender user at the one of the subset of the multiple sendermobile devices, in connection with the delivery of the amount of cashrequested.
 5. The computer-implemented method of claim 1, furthercomprising transmitting a confirmation of the exchange to the requestormobile device and/or the one of the subset of the sender mobile devices,after the digital transaction is approved and/or the amount isdelivered.
 6. The computer-implemented method of claim 1, furthercomprising: validating a session ID from a software development kit(SDK) in the application of the requestor mobile device for the request;and associating the response and/or the acceptance with the requestbased on the session ID included in the response and/or the acceptance.7. The computer-implemented method of claim 1, wherein the responseincludes a biometric and/or a facial image of the sender associated withthe one of the subset of the multiple sender mobile devices.
 8. Thecomputer-implemented method of claim 7, further comprising causing thebiometric and/or the facial image to be displayed to the requestor atthe requestor mobile device, in connection with the delivery of theamount.
 9. The computer-implemented method of claim 1, wherein thedigital transaction includes a person-to-person (P2P) digitaltransaction; and wherein the method further comprises facilitating theP2P transaction for the amount between said first account and saidsecond account.
 10. A system for use in facilitating a networktransaction, the system comprising: a backend server configured to:receive a cash request from a wallet application of a requestor mobiledevice associated with a requestor user, wherein the cash requestincludes an amount of cash requested and a location of the requestormobile device, and wherein the requestor user is associated with a firstpayment account; poll multiple sender mobile devices for location data,each of the sender mobile devices associated with a sender user; receivelocation data from each of the multiple sender mobile devices, wherein asubset of the multiple sender mobile devices is within a distance ofsaid location of the requestor mobile device; transmit the cash requestto the subset of the multiple sender mobile devices; receive a cashresponse from one of the subset of the multiple sender mobile devices,wherein the cash response includes a meet location and an estimatedtime; present the cash response to the wallet application of therequestor mobile device; and in response to an acceptance of the cashresponse from the requestor user at the wallet application of therequestor mobile device, transmit the acceptance to the one of thesubset of the sender mobile devices, to thereby enable delivery of theamount of cash requested to the requestor user in exchange for a digitaltransaction from said first payment account to a second payment accountassociated with the sender user of the one of the subset of the sendermobile devices.
 11. The system of claim 10, wherein the cash requestfurther includes a biometric and/or a facial image of the requestoruser.
 12. The system of claim 11, wherein the backend server is furtherconfigured to validate the cash request, based on the biometric and/orthe facial image of the requestor user included in the cash request,prior to polling the sender mobile devices.
 13. The system of claim 11,wherein the backend server is further configured to cause the biometricand/or the facial image to be displayed to the sender user at the one ofthe subset of the multiple sender mobile devices, in connection with thedelivery of the amount of cash requested.
 14. The system of claim 10,wherein the backend server is further configured to transmit aconfirmation of the exchange to the requestor mobile device and/or theone of the subset of the sender mobile devices, after the digitaltransaction is approved and/or the amount of cash requested isdelivered.
 15. The system of claim 10, wherein the backend server isfurther configured to: validate a session ID from an SDK in the walletapplication of the requestor mobile device for the cash request; andassociate the cash response and/or the acceptance with the cash requestbased on the session ID included in the cash response and/or theacceptance.
 16. The system of claim 10, wherein the cash responseincludes a biometric and/or a facial image of the sender associated withthe one of the subset of the multiple sender mobile devices; and whereinthe backend server is further configured to cause the biometric and/orthe facial image to be displayed to the requestor at the requestormobile device, in connection with the delivery of the amount of cashrequested.
 17. The system of claim 10, wherein the digital transactionincludes a person-to-person (P2P) digital transaction; and wherein thebackend server is further configured to facilitate the P2P transactionfor the amount of cash requested between said first payment account andsaid second payment account.
 18. A non-transitory computer-readablestorage medium including executable instructions for facilitating anetwork transaction, which when executed by a processor, cause theprocess to: receive a cash request from a wallet application of arequestor mobile device associated with a requestor user, the cashrequest including an amount of cash requested and a location of therequestor mobile device, wherein the requestor user is associated with afirst payment account; poll multiple sender mobile devices for locationdata, each of the multiple sender mobile devices associated with asender user; receive location data from each of the multiple sendermobile devices, wherein a subset of the multiple sender mobile devicesis within a distance of said location of the requestor mobile device;transmit the cash request to the subset of the multiple sender mobiledevices; receive a cash response from one of the subset of the multiplesender mobile devices, the cash response including a meet location andan estimated time; present the cash response to the wallet applicationof the requestor mobile device; and in response to an acceptance of thecash response from the requestor user at the wallet application of therequestor mobile device, transmit the acceptance to the one of thesubset of the sender mobile devices, to thereby enable delivery of theamount of cash requested to the requestor user in exchange for a digitaltransaction from said first payment account to a second payment accountassociated with the sender user of the one of the subset of the sendermobile devices.